Every renewal season, some controls engineer with a few Ignition projects under their belt looks at the MES line item on the budget and asks a reasonable question: why are we buying this when we could build it? Inductive Automation’s Ignition platform, with its unlimited-licensing model and the Perspective module’s drag-and-drop web app builder, has made that question harder to wave away than it used to be. This isn’t a hypothetical anymore — it’s a live alternative showing up next to Opcenter, Plex, and Tulip in the same RFP.
It deserves a serious answer, not a reflexive one in either direction.
What Ignition actually is, and why this comparison exists at all
Ignition started as a SCADA/HMI platform built around a tag-based architecture, an SQL-friendly historian, and a server-centric licensing model that lets you deploy to as many clients and screens as you want without per-seat fees. Vision was its original web-launched visualization module; Perspective, introduced later, is the modern web-native equivalent — HTML5-based, mobile-responsive, and built for building actual applications, not just HMI screens.
That last point is the crux of this whole debate. Perspective’s component model, scripting via Python (Jython under the hood), and native integration with Ignition’s tag system and database connections make it genuinely capable of producing things that look and behave like MES modules: work-order dispatch screens, genealogy trees, andon boards, downtime tracking, even scheduling views. None of that requires a dedicated MES product license. It requires an Ignition license you may already own for SCADA, plus engineering time.
That’s the pitch. It’s not wrong. It’s just incomplete until you price in the second half.
Where building it in Ignition genuinely wins
For narrowly scoped, plant-specific problems, Ignition’s approach has real advantages over a packaged MES module.
- You already have the data layer. If your Ignition SCADA is already collecting the tags, alarms, and historian data you need, an andon or downtime module built on top of that data is a much shorter path than standing up a separate MES platform’s data collection layer and integrating it back to the same PLCs.
- You control the exact workflow. Dedicated MES platforms ship with an opinionated model of how scheduling, genealogy, or quality holds should work. If your process doesn’t map cleanly onto that model, you spend real effort configuring around the edges. A custom Perspective screen can match your actual shop-floor logic exactly, including the weird exceptions that don’t fit a standard template.
- Licensing scales differently. Ignition’s unlimited-client model means adding twenty more operator stations or a new line doesn’t trigger a new per-seat or per-tag negotiation the way some MES and even some SCADA licensing models do. For plants adding screens and lines over time, that matters.
- Iteration speed on small changes is fast. Because you own the code, a tweak to a genealogy screen or an andon rule is a same-week change, not a change request routed through a vendor’s professional services queue.
These are real, defensible reasons to build. They’re strongest when the scope is genuinely narrow — one or two modules, one plant, a team that already has Ignition chops in-house.
Where the total cost of ownership quietly flips
The build-versus-buy math almost always looks good in year one, because year one is mostly development labor you’re already budgeting for the SCADA project anyway. The flip tends to show up in years two and three, for reasons that are well understood in software engineering generally but easy to underweight in a plant-floor context.
Validation and change control compound
In regulated environments — pharma, medical device, food safety with strong traceability requirements — every MES-like function you build yourself becomes something your quality system has to validate and revalidate on every change. Packaged MES platforms from vendors like Siemens (Opcenter), Rockwell/Plex, or Tulip carry established validation documentation and change-management practices that you inherit rather than author. A custom Perspective genealogy module puts you in the business of writing and maintaining that validation package yourself, indefinitely. That’s not a knock on Ignition’s engineering quality — it’s a statement about who owns the documentation burden, and it’s substantial in a GxP shop.
The person who built it leaves
This is the single most common failure mode in home-grown shop-floor software, full stop, across every platform, not just Ignition. The scheduling module works great until the controls engineer who wrote the Python scripts moves to another company, and the next person has to reverse-engineer undocumented logic under production pressure. Dedicated MES platforms don’t eliminate this risk entirely, but they bound it — the vendor’s documentation, support contract, and broader user base mean the knowledge doesn’t live in exactly one person’s head.
Feature parity creep
The first version of an andon module is genuinely simple to build. Then someone asks for shift-based escalation rules, then multi-language support, then integration with a new ERP, then mobile push notifications. Each addition is individually reasonable and individually cheap. Three years in, you’ve built — and now must maintain — a bespoke application with the surface area of a real MES module, minus the vendor’s QA process, release notes, and backward-compatibility testing.
Support is now an internal cost center
When a packaged MES module misbehaves, you open a support ticket. When your custom Perspective app misbehaves at 2 a.m., you page your own engineer — and if that engineer is unavailable, production waits. Some plants are fine absorbing that risk. Others are quietly self-insuring against a failure mode they haven’t priced.
How this stacks up against Opcenter, Plex, and Tulip specifically
Opcenter (Siemens) and Plex (Rockwell) are the deepest, most process-model-driven options here, with strong genealogy, quality, and scheduling capability out of the box — and correspondingly heavier implementation projects and more rigid configuration models. Tulip sits closer to Ignition philosophically: low-code, app-based, fast to stand up narrow use cases like work instructions and andon. In our assessment, Tulip and Ignition compete most directly for the “we just need a few shop-floor apps” segment, while Opcenter and Plex compete for shops that need enterprise-wide scheduling, genealogy, and quality integrated as one coherent system with vendor-owned validation packages.
None of these are strictly better — they fit different shops.
Who should build, who should buy
Building in Ignition tends to fit plants with in-house controls talent who already run Ignition SCADA, a narrow and stable set of MES functions to cover, and no heavy regulatory validation burden. It may not suit shops that operate under strict quality validation regimes, that need broad MES scope (scheduling, genealogy, quality, and performance analysis all integrated), or that don’t have — and don’t want to build — an internal team capable of owning that code for the long haul.
The honest way to run the evaluation this renewal season is to price the packaged MES option against a fully loaded three-year build cost that includes documentation, validation maintenance, and a credible answer to “what happens when the builder leaves” — not just the sprint to get version one running. Ignition earns its place in a lot of plants. It earns a smaller place than the demo makes it look like it deserves.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
